1. Field of the Invention
The present invention relates to a server of a data communication system in which one or more clients are provided by the server with an instruction data set in a particular instruction format in response to a content data request message issued by the client. In particular, the present invention provides a mechanism by which the instruction format of the instruction data set (for example, an HTML page) can be adapted, modified or varied depending on properties of the client as determined from the content data request message.
2. Description of the Related Art
Computers have been conveniently used for a wide range of applications, i.e., ranging from simple editing of text documents to complex distributed processing applications involving a large number of possibly distributed data processing units and involving the transfer of data between the data processing units.
With the growing number of data processing units having access to computer networks such as local area networks or world-wide networks, i.e., company-wide intranets or the Internet, a growing number of applications are offered which involve a plurality of data processing units. Such applications may be, for example, found in the field of home banking, office applications, remote e-mail applications, supercomputing applications or the like. In such data communication systems, high speed links, via permanent connections, circuit-switched connections or packet-switched connections, are used as communication links to exchange digital data at high speed (high-bit rates) such that even graphics data or data from moving images can be exchanged among the data processing units.
It is a typical feature in such data communications systems that it is not required that all participating data processing units have the same powerful processing capabilities. That is, a main computer having powerful computing facilities can serve a number of smaller sub-computers through one or more of the above-described communication links. Since typically the smaller sub-computers are only assigned the task of making access to a main computer and to request the processing facilities or data from the main computer whilst the main computer serves the data on the small sub-computers, the main computer is often referred to as a server and the small sub-computers are referred to as clients. In such a scenario a client may typically request the execution of an application program at the server and may receive a data processing result or content data from the server via the network or the communication link connecting the client and the server.
Furthermore, systems are known where a plurality of clients can connect to a portal for the execution of an application. A portal may be a large site in a network including a plurality of servers which provide a variety of services including, for example, office applications, searching functions, news functions, e-mail applications, discussion groups, on-line shopping and links to other sites on the network. A portal may thus, be a general purpose site offering the capability to perform applications on behalf of a client or assisting a client in executing the application.
Generally, in a client and server or portal scenario the server may be a large computing device which has also the resources to store and execute application programs which are used in providing services to a client. Since the applications and sufficient computing power are generally available at the server side, the client may be a data processing unit with less powerful computing resources, functioning as an interface to receive user commands required for execution of a desired application program when providing the request, i.e., to transmit commands from the client to the server, and further to receive and, for example, to display computation results from the server.
a. Conventional Server and Client Configuration
A typical data communication system 00 of the prior art is shown in FIG. 1. Here, a server 10 and clients 11, 12, 13, 14, . . . , 15 communicate through communication links 20, possibly through an intranet 21 and/or the Internet 22. FIG. 2 shows a typical block diagram of a server 10 and a client 11 in accordance with the prior art. The server 10 and the client 11 communicate through a communication link 20 connected to a respective communication interface 23, 40.
Typically, the server 10 includes a server processor 26, a memory 27 with programs 28, the programs 28 having a data structure 29 therein, and a secondary storage 30, all connected by a bus 31.
Typically, the client 11 includes a client processor 41, a memory 42 with programs 43, the programs 43 having a data structure 44, a display 45 and an input 46.
FIG. 3 shows an example of operations or steps typically carried out by the client side and the server side for the typical scenario in FIG. 1.
b. Conventional Transfer of Content Data to the Client
For example, in case a user at a client side wishes to access a document from the server 10, i.e., a web-page available at the server 10 or another location, the user selects in step ST1 one of the programs 43 in memory 42, i.e., a particular browser, which is run on the client processor 41.
When the user clicks on a particular place on the screen, the program 42 sends a content data request CDRQ to the server 10 in step ST2. In the Internet protocol, such a request message CDRQ can typically be an HTPP message requesting the transfer, for example, of HTML-pages from a database 30 located within the server 10 (or located elsewhere outside the server 10), where the content data is stored. In this example, the HTTP-request message includes the URL from which the HTML-pages should be retrieved and some additional header information.
After setting up the communication link 20 between the client 11 and the server 10, the program 27 receives the content data request message CDRQ on the server side, in step ST3. Alternatively, the client 11 can also request the execution by the server 10 of some processing programs 27 in memory 28, so-called servlets or JAVAserver pages if the server is a JAVA® based server (JAVA® is a registered trademark of Sun Microsystems).
In step ST4, the program 27 statically or dynamically retrieves the requested content data, i.e., the HTML-pages. In a static retrieval, the program 27 by server processing unit 26 merely accesses a local database 30 and retrieves the content data, i.e., the HTML-pages. In a dynamic retrieval, the program 27 retrieves data also from a remote site in a dynamic manner. After the step ST4, a step ST5 follows in which the format of the content data for the client 11 is determined. This will be explained below.
In step ST6, the program 27 of the server 10 provides through the communication link 20 the retrieved content data, i.e., an instruction data set to the client side. In step ST7, the content data or the instruction data set is received on the client side by program 43, and in step ST8, the user at the client side has the option to display or print out the transferred content data on a display 45, on a disc, or a printer. If the requested content data are for example, web-pages (HTML-pages), typically complete data sets relating to one page are requested by program 43 and re-transferred to the client side. Therefore, if in step ST9 the user requires more content data, for example, further pages, i.e., data sets, from the server 10, the process continues with step ST2. If no further content data are required, the link 20 is closed after some time, for example, by stopping the browser in step ST10.
c. Structure of the Instruction Data Set
FIG. 4 shows an example of the HTTP request and HTTP reply scenario between the client 11 and the server 10 for the case where the data set to be transferred back to the client 11 contains content data which on the client 11 is to be used for a screen display. As shown in FIG. 4, in this example using HTML-pages, the HTML-page includes a screen layout format including a plurality of screen elements 51, 52. Here, the screen element 51 is a log-in element and the screen element 52 is a company logo. Furthermore, the screen layout 50 can, for example, include a particular background colour. That is, in the case of FIG. 4 the screen format is constituted by a data set which includes graphics data. In order for the client 11 to recognize that the transferred data set includes graphic element data sets, the program 28 includes an instruction format setup sequence on the server side to determine a so-called MIME-type which indicates the type of data contained in the HTML-page, used in this example, to be transferred to the client 11. Therefore, in the step ST5 in FIG. 3, the program 28 determines the MIME-type and transfers an indication of the MIME-type to the client 11 together with the data set in step ST6. On the basis of the MIME-type, the program 43 at the client 11 can recognize that the transferred data sets include graphics element data sets which can be displayed on the display 45. Thus, in this case, the transferred HTML-page used in this example, is intended merely for being displayed on the display screen 45.
However, the transferred data sets from the server 10 may not only constitute a graphics data set to be displayed on a display screen but can also be a general instruction data set which the user can use for other purposes in step ST8. For example, the user at the client 11 may request a transfer of a command data set for controlling a device on a client side, for example, a robot. That is, the client 11 may not necessarily use the transferred data set for a display but for a control of a device.
While in this case there is no necessity to display the commands on the display screen, the HTML-page used in this example, which is transferred from the server 10 by program 28, will nonetheless have a particular instruction format similar to the one shown for the screen layout in FIG. 4. That is, when the command data set is requested by program 43, it will also contain specific instruction elements corresponding to instruction element data sets in the instruction data set to be transferred to the client 11.
Hence, independently of what use is made at the client 11, every transferred instruction data set from server 10 will have a particular instruction format consisting of a plurality of instruction elements and the MIME-type will indicate to the client 11 the type of data which is transferred.
Thus, generally an instruction data set is transferred back to the client 11 by program 28 and this instruction data set will include a plurality of instruction element data sets corresponding to the particular instruction elements forming the data set. Therefore, display frames for local visualization at the client side or command frames for other use at the client side can be transmitted by program 28 from the server 10 to the client 11 as, for example, HTML-pages.
d. Structure of Data Requests
Furthermore, while in the above description it has been assumed that the program 43 merely sends a content data request CDRQ to the server 10, of course, more complex operation commands can be transmitted to the server side in a similar manner. For example, in case the client 11 wishes to scroll through a document, a corresponding input command is given via input 46 to the browser and is transmitted via the communication link 20 to the server 10. In turn, the program 28 at the server 10 prepares a corresponding display content for transfer to the client 11 in order to enable the client 11 to locally visualize the changed display content. Similarly, in case the user wishes to edit the document, respective commands could be transmitted from the program 43 at the client 11 to the server 10 and accordingly be processed at the server 10. Changed display contents (content data) can then again be transmitted to the client 11 for the local visualization on the display 45.
However, it is also possible, that not only the server 10 has the necessary resources to provide a desired service, but a client 11 may already have the required resources for providing the service such as rendering operations or editing a data file. Corresponding application programs may thus be available at both the client side, i.e., an applet, and the server side, i.e., a servlet, for performing a desired operation, i.e., providing a desired service. Such programs are also available as one of the programs 43 shown on the client side in FIG. 2.
Since on the client side different browsers or different processing programs 43 can be executed or different devices can be used on the client side, the server side must also have knowledge about what type of program is run in order to determine in which manner the retrieved content data should be provided back to the client 11.
Typically, when the program 43 issues the content data request CDRQ, the request also contains request parameters, request header parameters, device properties and resource properties.
Device properties are used in conjunction with the client 11. These properties refer to such things as the different display sizes of the client devices.
Resource properties cover all the properties that are assigned to a requested document or more generally to a resource. This, for example, includes the various document types (Star Office documents, Star Office write, Star Office calculator or other document formats such as PDF as well as customized content types used for folders, for example).
Since the server 10 can be accessed by different browsers, for example, Netscape browser 4.X and the Internet Explorer, special add-ins are required in each browser such that a document can be edited. To enable the dynamic download of the correct add-in, the browser type can be identified via request header parameters of the request message CDRQ.
Finally, for the above-described custom commands issued by the program 43 at the client 11, so-called request parameters are available in the request message CDRQ such that the commands can be recognized on the server side.
e. Disadvantages
Despite the fact that according to the prior art it is already possible to transfer in the content data request CDRQ (i.e., a HTTP-request) information of the request parameters, request header parameters, device properties and resource properties, the program 28 at the server 10 simply retrieves the content data (i.e., HTML-page) and determines the MIME-type and then provides back to the client 11 a corresponding data set including a fixed instruction format determined by the MIME-type. That is, despite the fact that some information about the client properties and/or resource properties are transferred to the server 10 in the request message CDRQ sent by program 43, the format of the data set transferred back to the client 11 by program 28 is fixed, i.e., independent of the properties. Thus, independent of the capabilities of the client 11, the same format will always be used (only the MIME-type is determined to tell the client 11 what type of data is retransferred). Consequently, the program 28 uses a page set up which is a rather fixed frame or instruction data set format when re-transferring the requested data. Thus, the main disadvantage results that, independently of the capabilities of the client device, the executed browsing program, the set options on the browsing program and the type and size of the requested content data, the instruction format (screen format or command format) remains the same.
That is, it would generally be desirable to provide a flexible and extendable framework for creating content depending on the client 11 or resource properties, i.e., the server 10 should be capable of changing the instruction format depending on the client capabilities and the type of requested content data.